-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Replace redundant sections with link to the typing documentation #7594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this removes too much. I'm on board with shortening this text, but some parts are typeshed-specific and should be kept, and others aren't yet covered in the typing docs.
A few guidelines for protocol names below. In cases that don't fall | ||
into any of those categories, use your best judgement. | ||
|
||
* Use plain names for protocols that represent a clear concept |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't in the linked doc
context manager is meant to be subclassed, pick `bool | None`. | ||
See https://github.com/python/mypy/issues/7214 for more details. | ||
|
||
`__enter__` methods and other methods that return instances of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The typing docs don't mention this
be used in typeshed as soon as the PEP has been accepted and implemented | ||
and most type checkers support the new feature. | ||
|
||
Accepted features that *cannot* yet be used in typeshed include: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this list is still useful, and it makes sense to keep it in typeshed because it's specifically about this repo's policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, I kind of forgot about this PR.
Maybe it's best to link to https://github.com/python/typeshed/issues?q=is%3Aissue+is%3Aopen+label%3Afeature-tracker, instead of listing the missing features? The issues are more likely to be kept up-to-date than the list in CONTRIBUTING.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, sounds good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also consider using a meta-issue tracker to track the issue trackers. The advantage of using an issue to track the issue trackers is that items will automatically be ticked off as completed if issue trackers on the bullet-pointed list are closed. We could link to the meta-issue tracker from CONTRIBUTING.md
and pin it on the issue tracker.
Are there parts of this we still want? Shortening |
No description provided.